<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.29
     from pp.tnf on 19 December 2010 -->

<TITLE>Products and Parameters Reference - Generating Specifications</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#FF0000" BACKGROUND="gifs/bg.gif">
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0" VALIGN=BOTTOM>
<TR VALIGN=BOTTOM>
<TD WIDTH="160" VALIGN=BOTTOM>
<A HREF="http://eli-project.sourceforge.net/">
<IMG SRC="gifs/elilogo.gif" BORDER=0>
</A>&nbsp;
</TD>
<TD WIDTH="25" VALIGN=BOTTOM>
<img src="gifs/empty.gif" WIDTH=25 HEIGHT=25>
</TD>
<TD ALIGN=LEFT WIDTH="475" VALIGN=BOTTOM>
<A HREF="index.html"><IMG SRC="gifs/title.png" BORDER=0></A>
</TD>
<!-- |DELETE FOR SOURCEFORGE LOGO|
<TD>
<a href="http://sourceforge.net/projects/eli-project">
<img
  src="http://sflogo.sourceforge.net/sflogo.php?group_id=70447&amp;type=13"
  width="120" height="30"
  alt="Get Eli: Translator Construction Made Easy at SourceForge.net.
    Fast, secure and Free Open Source software downloads"/>
</a>
</TD>
|DELETE FOR SOURCEFORGE LOGO| -->
</TR>
</TABLE>

<HR size=1 noshade width=785 align=left>
<TABLE BORDER=0 CELLSPACING=2 CELLPADDING=0>
<TR>
<TD VALIGN=TOP WIDTH="160">
<h4>General Information</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="index.html">Eli: Translator Construction Made Easy</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="gindex_1.html#SEC1">Global Index</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="faq_toc.html" >Frequently Asked Questions</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ee.html" >Typical Eli Usage Errors</a> </td></tr>
</table>

<h4>Tutorials</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="EliRefCard_toc.html">Quick Reference Card</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="novice_toc.html">Guide For new Eli Users</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="news_toc.html">Release Notes of Eli</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="nametutorial_toc.html">Tutorial on Name Analysis</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="typetutorial_toc.html">Tutorial on Type Analysis</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ee.html" >Typical Eli Usage Errors</a> </td></tr>
</table>

<h4>Reference Manuals</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ui_toc.html">User Interface</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="pp_toc.html">Eli products and parameters</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lidoref_toc.html">LIDO Reference Manual</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ee.html" >Typical Eli Usage Errors</a> </td></tr>
</table>

<h4>Libraries</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lib_toc.html">Eli library routines</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="modlib_toc.html">Specification Module Library</a></td></tr>
</table>

<h4>Translation Tasks</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lex_toc.html">Lexical analysis specification</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="syntax_toc.html">Syntactic Analysis Manual</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="comptrees_toc.html">Computation in Trees</a></td></tr>
</table>

<h4>Tools</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lcl_toc.html">LIGA Control Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="show_toc.html">Debugging Information for LIDO</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="gorto_toc.html">Graphical ORder TOol</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="fw_toc.html">FunnelWeb User's Manual</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ptg_toc.html">Pattern-based Text Generator</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="deftbl_toc.html">Property Definition Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="oil_toc.html">Operator Identification Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="tp_toc.html">Tree Grammar Specification Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="clp_toc.html">Command Line Processing</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="cola_toc.html">COLA Options Reference Manual</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="idem_toc.html">Generating Unparsing Code</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="mon_toc.html">Monitoring a Processor's Execution</a> </td></tr>
</table>

<h4>Administration</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="sysadmin_toc.html">System Administration Guide</a> </td></tr>
</table>

<HR WIDTH="100%">
<A HREF="mailto:eli-project-users@lists.sourceforge.net">
<IMG SRC="gifs/button_mail.gif" BORDER=0 ALIGN="left"></A>
<A HREF="index.html"><IMG SRC="gifs/home.gif" BORDER=0 ALIGN="right"></A>

</TD>
<TD VALIGN=TOP WIDTH="25"><img src="gifs/empty.gif" WIDTH=25 HEIGHT=25></TD>

<TD VALIGN=TOP WIDTH="600">
<H1>Products and Parameters Reference</H1>
<P>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="pp_1.html"><IMG SRC="gifs/prev.gif" ALT="Previous Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="pp_3.html"><IMG SRC="gifs/next.gif" ALT="Next Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="pp_toc.html"><IMG SRC="gifs/up.gif" ALT="Table of Contents" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT="">
<HR size=1 noshade width=600 align=left>
<H1><A NAME="SEC10" HREF="pp_toc.html#SEC10">Generating Specifications</A></H1>
<P>
Sometimes a common problem can be solved by a collection of specifications
having a particular structure.
These specifications themselves can be generated, given simpler
specifications.
The products and parameters described in this chapter are most often used
in requests that appear in type-<CODE>specs</CODE> files.
They result in specifications that are then used to describe the complete
processor.
<P>
<H2><A NAME="SEC11" HREF="pp_toc.html#SEC11">consyntax -- Concrete Syntax</A></H2>
<P>
<A NAME="IDX34"></A>
<PRE>
:consyntax
</PRE>
<P>
Requesting <CODE>:consyntax</CODE> will result in a type-<TT>`con'</TT> file
containing the complete concrete syntax.  This includes all concrete
syntax rules provided by the user in type-<TT>`con'</TT> files (translated
into strict BNF form) as well as rules added to the concrete
syntax as a result of the mapping process
(see  <A HREF="syntax_2.html#SEC8">Mapping of Syntactic Analysis</A>).
<P>
<H2><A NAME="SEC12" HREF="pp_toc.html#SEC12">abstree -- Abstract Tree Grammar</A></H2>
<P>
<A NAME="IDX35"></A>
<PRE>
:abstree
</PRE>
<P>
Requesting <CODE>:abstree</CODE> will result in a type-<TT>`lido'</TT> file
containing the complete abstract tree grammar.
This consists of all rules supplied by the user in
type-<CODE>lido</CODE> files, plus any additional rules derived from rules
appearing only in type-<CODE>con</CODE> files in the syntax mapping process
(see  <A HREF="syntax_2.html#SEC8">Mapping of Syntactic Analysis</A>).
<P>
<H2><A NAME="SEC13" HREF="pp_toc.html#SEC13">absyntax -- Abstract Syntax</A></H2>
<P>
<A NAME="IDX36"></A>
<PRE>
:absyntax
</PRE>
<P>
Requesting <CODE>:absyntax</CODE> will result in a type-<CODE>lido</CODE> file
containing the complete abstract syntax.
This derivation differs from the <CODE>:abstree</CODE> derivation
(see  <A HREF="pp_2.html#SEC12">abstree -- Abstract Tree Grammar</A>) in that rules which can only be derived
for computed subtrees
(see  <A HREF="lidoref_10.html#SEC18">Computed Subtrees of LIDO - Reference Manual</A>)
are not included.
<P>
<H2><A NAME="SEC14" HREF="pp_toc.html#SEC14">pgram -- Parsing Grammar</A></H2>
<P>
<A NAME="IDX37"></A>
<PRE>
:pgram
</PRE>
<P>
The parsing grammar requested by the <CODE>:pgram</CODE> derivation is the
input to the parser generator.  This includes the integer encodings of the
terminal symbols, any directives supplied by the user to direct
the automatic error correction of the parser, and each of the BNF rules
in the concrete syntax with associated actions.  These actions include
actions supplied by the user as well as actions generated to construct
an abstract syntax tree.
<P>
Note that the mapping process may cause the injection of certain chain
rules due to <CODE>BOTTOMUP</CODE> constraints specified in the attribute
<A NAME="IDX38"></A>
grammar.  These injected rules do not appear in the result of the
<CODE>:consyntax</CODE> derivation, which makes <CODE>:pgram</CODE> the most appropriate
derivation to consult when trying to resolve parsing conflicts which may
have resulted from the injection of these chain rules.
See  <A HREF="syntax_2.html#SEC18">BOTTOMUP of Syntactic Analysis</A>.
<P>
<H2><A NAME="SEC15" HREF="pp_toc.html#SEC15">kwd -- Recognize Specified Literals as Identifiers</A></H2>
<P>
<A NAME="IDX39"></A>
<PRE>
<VAR>file</VAR>.gla :kwd
</PRE>
<P>
Specifications that force literals whose lexical structure is defined by
<CODE><VAR>file</VAR>.gla</CODE> to be handled specially by the generated scanner.
<A NAME="IDX40"></A>
<P>
Normally, each literal found in the context-free grammar is recognized
explicitly by the scanner as the specified character sequence.
This is in contrast to identifiers, denotations and comments,
whose lexical structures are defined by regular expressions.
The literals are defined by their appearance in the grammar, and no
type-<CODE>gla</CODE> file describes their structure.
<P>
The <CODE>:kwd</CODE> product is used when literals are representative of the
character strings
<A NAME="IDX41"></A>
that should appear in the program, but not necessarily identical to them.
The classic case in which <CODE>:kwd</CODE> would be used (and from which its
name is derived) is the recognition of mixed-case keywords.
<A NAME="IDX42"></A>
A literal <CODE>'if'</CODE> appearing in a Pascal grammar is representative of
the character strings <CODE>if</CODE>, <CODE>If</CODE>, <CODE>iF</CODE> and <CODE>IF</CODE> but is
identical to only the first.
Whenever any one of these four character strings appears in a Pascal
program, it should be recognized by the scanner as an instance of the
literal <CODE>'if'</CODE>.
All Pascal keywords behave in this fashion, and each has the form of an
identifier.
<P>
Suppose that file <CODE>pkeys.gla</CODE> defines the structure of the literals
used in the grammar, and the following line were added to one of the
type-<CODE>.specs</CODE> files for a Pascal compiler:
<P>
<PRE>
pkeys.gla :kwd
</PRE>
<P>
This would prevent the scanner of the generated compiler from recognizing
Pascal keywords explicitly as the character sequences specified
by the literals given in the grammar.
Other literals (such as <CODE>:=</CODE>), which did not fit the definition given
by <CODE>pkeys.gla</CODE>, would still be recognized by the scanner as the
specified character sequences.
<P>
It is important to remember that the type-<TT>`gla'</TT> file to which the
<CODE>kwd</CODE> derivation is applied defines the form of the literals <EM>in
the grammar</EM>, not in the input text.
<P>
<H2><A NAME="SEC16" HREF="pp_toc.html#SEC16">inst -- Instantiate a Generic Module</A></H2>
<P>
<A NAME="IDX43"></A>
<PRE>
<VAR>file</VAR>.gnrc :inst
</PRE>
<P>
A specification consisting of one or more files is generated from
<CODE><VAR>file</VAR>.gnrc</CODE>.
<A NAME="IDX44"></A>
This product is normally used to instantiate the common problem solutions
that have been stored in the library
<A NAME="IDX45"></A>
(see  <A HREF="modlib_2.html#SEC2">Module Instantiation of Specification Module Library</A>):
<P>
<PRE>
$elipkg/Name/AlgScope.gnrc :inst
</PRE>
<P>
Here the path <TT>`$elipkg/Name'</TT> accesses the portion of the library
devoted to problems arising in the context of name analysis
<A NAME="IDX46"></A>
(see  <A HREF="name_toc.html">Name Analysis Library of Specification Module Library: Name Analysis</A>).
<P>
Type-<CODE>gnrc</CODE> files can be supplied by a user.
<A NAME="IDX47"></A>
They are simply shell scripts that carry out whatever
actions are needed to instantiate a generic specification.
Thus a user of Eli can construct generic specifications
<A NAME="IDX49"></A>
<A NAME="IDX48"></A>
appropriate to a specific domain
<A NAME="IDX50"></A>
and use them exactly like library specifications.
<P>
Scripts appearing as type-<CODE>gnrc</CODE> files are invoked
<A NAME="IDX52"></A>
<A NAME="IDX51"></A>
with up to three parameters.
The first parameter is the <CODE>sed</CODE>(1) program,
the second parameter is the string specified by <CODE>+instance</CODE>,
and the third parameter is the string specified by <CODE>+referto</CODE>.
When the script is invoked, its full path name is used.
Therefore the script can determine the directory in which it is stored,
and access specific files in that directory.
<P>
Here is an example of a type-<CODE>gnrc</CODE> file,
<TT>`$elipkg/Name/AlgScope.gnrc'</TT>:
<P>
<PRE>
#!/bin/sh
# $Id: pp.tnf,v 2.14 2008/06/12 21:15:29 profw Exp $
# Copyright, 1994, AG-Kastens, University Of Paderborn

moddir=`expr $0 : '\(.*\)/.*' \| '.'`

$1 -e "s/|NAME|/$2/g
s/|KEY|/$3/g" "$moddir"/AlgScope.fw &#62; "$2"AlgScope.fw
</PRE>
<P>
It first sets <CODE>moddir</CODE> to the name of the directory in which it resides,
then uses <CODE>sed</CODE> to modify file <TT>`AlgScope.fw'</TT> in that directory.
The script replaces the string <CODE>|NAME|</CODE> with the string specified by the
<CODE>+instance</CODE> parameter of the original request.
(If no <CODE>+instance</CODE> parameter was supplied, <CODE>$1</CODE> is empty and
every occurrence of the string <CODE>|NAME|</CODE> is simply deleted.)
Similarly, it either replaces the string <CODE>|KEY|</CODE> with the string
specified by the <CODE>+referto</CODE> parameter or deletes it.
Finally, the name of the output file depends on the
<CODE>+instance</CODE> parameter of the original request.
<P>
The output file will become part of the specification that contained the
<CODE>:inst</CODE> request.
<P>
<H2><A NAME="SEC17" HREF="pp_toc.html#SEC17">ExpInfo -- Information about remote attribute access</A></H2>
<P>
<A NAME="IDX53"></A>
<PRE>
:ExpInfo
</PRE>
<P>
Obtain information about the processing of LIDO specifications,
especially
information concerning the expansion of remote attribute accesses
(i. e. INCLUDING, CONSTITUENTS, and CHAIN). The generated listing
describes how each remote access construct can be replaced by a
set of equivalent computations propagating the accessed values through
adjacent contexts. This file is useful if special difficult cases
regarding problems with remote dependences arise.
<P>
Additional information about attribute dependences and attribute
storage optimization can be obtained by adding the parameters <CODE>+OrdI</CODE> and
<CODE>+OptimI</CODE>. 
<P>
<PRE>
Example: foo.specs+OrdI:ExpInfo&#62;
</PRE>
<P>
For a more detailed description of Liga's protocol options
and more advanced options, see 
 <A HREF="lcl_toc.html">Liga Control Language Manual of Liga Control Language Manual</A>.
<P>
<H2><A NAME="SEC18" HREF="pp_toc.html#SEC18">OrdInfo -- Information about attribute dependence</A></H2>
<P>
<A NAME="IDX54"></A>
<PRE>
:OrdInfo
</PRE>
<P>
Obtain information about the processing of LIDO specifications,
especially
information concerning the attribute dependences.
The protocol provides for each grammar rule the set of direct 
dependences between attributes occurring in this rule.
<P>
Additional information about remote attribute access and attribute
storage optimization can be obtained by adding the parameters 
<CODE>+ExpI</CODE> and
<CODE>+OptimI</CODE>. 
<P>
<PRE>
Example: foo.specs+ExpI:OrdInfo&#62;
</PRE>
<P>
For a more detailed description of Liga's protocol options
and more advanced options, see 
 <A HREF="lcl_toc.html">Liga Control Language Manual of Liga Control Language Manual</A>.
<P>
<H2><A NAME="SEC19" HREF="pp_toc.html#SEC19">OptimInfo -- Information about attribute storage optimization</A></H2>
<P>
<A NAME="IDX55"></A>
<PRE>
:OptimInfo
</PRE>
<P>
Obtain information about the processing of LIDO specifications,
especially
information on attribute storage optimization.
For each attribute this protocol provides information where this
attribute is stored. Possible storage locations are "tree node",
"global variable" and "global stack".
<P>
Additional information about remote attribute access and attribute
dependences can be obtained by adding the parameters <CODE>+ExpI</CODE> and
<CODE>+OrdI</CODE>. 
<P>
<PRE>
Example: foo.specs+ExpI:OptimInfo&#62;
</PRE>
<P>
For a more detailed description of Liga's protocol options
and more advanced options, see 
 <A HREF="lcl_toc.html">Liga Control Language Manual of Liga Control Language Manual</A>.
<P>
<H2><A NAME="SEC20" HREF="pp_toc.html#SEC20">show -- LIDO Table Viewers showFe and showMe</A></H2>
<P>
<A NAME="IDX56"></A>
<PRE>
:showFe
<A NAME="IDX57"></A>:showMe
</PRE>
<P>
Obtain a list of files that contain internal representations of LIDO text
translated into readable text. <CODE>:showFe</CODE> shows LIDO text after
the processing by the frontend of the Liga-System, <CODE>:showMe</CODE> shows
the same information after attribute evaluator construction.
<P>
These informations can be useful for debugging a LIDO-Specification or
to understand LIGA-Processing in more depth.
<P>
See  <A HREF="show_toc.html">Overview of SHOW - Debugging Information for LIDO</A>, for more details.
<P>
<H2><A NAME="SEC21" HREF="pp_toc.html#SEC21">instance -- Name an Instance of a Generic Module</A></H2>
<P>
<A NAME="IDX58"></A>
<PRE>
+instance='<VAR>string</VAR>'
</PRE>
<P>
Use <VAR>string</VAR> to name the instance generated by the request.
<A NAME="IDX60"></A>
<A NAME="IDX59"></A>
No spaces are allowed within the <VAR>string</VAR>, and characters meaningful to
the shell that interprets the associated type-<CODE>gnrc</CODE> file may cause
problems.
<P>
Not all generic modules allow distinct instances to be created.
See the documentation of each such module for the precise effect of
<CODE>+instance</CODE>.
<P>
<H2><A NAME="SEC22" HREF="pp_toc.html#SEC22">referto -- Relate Instances of Generic Modules</A></H2>
<P>
<A NAME="IDX61"></A>
<PRE>
+referto='<VAR>string</VAR>'
</PRE>
<P>
Use <VAR>string</VAR> to relate the current instance of a generic module to some
specific instance of another generic module.
<P>
Not all generic modules allow relationships to be specified.
See the documentation of each such module for the precise effect of
<CODE>+referto</CODE>.
<P>
<HR size=1 noshade width=600 align=left>
<P>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="pp_1.html"><IMG SRC="gifs/prev.gif" ALT="Previous Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="pp_3.html"><IMG SRC="gifs/next.gif" ALT="Next Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="pp_toc.html"><IMG SRC="gifs/up.gif" ALT="Table of Contents" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT="">
<HR size=1 noshade width=600 align=left>
</TD>
</TR>
</TABLE>

</BODY></HTML>
